Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Wireless Networking Handbook
(Publisher: Macmillan Computer Publishing)
Author(s): Jim Geier
ISBN: 156205631x
Publication Date: 09/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


In addition to the active participants, JAD consists of a facilitator, scribe, and optional observers (see fig. 6.4). The facilitator manages the overall meeting, acting as a mediator and guide to guarantee the group stays focused on objectives and follows all JAD meeting rules. The facilitator should have good communication skills, be impartial to the project, have team building experience and leadership skills, be flexible, and be an active listener. The scribe records the proceedings of the JAD and should have good recording skills and some knowledge of the subject matter. It may be beneficial to have impartial observers monitor the JAD sessions and provide feedback to the facilitator and project manager. In addition, managers as observers can spot and take action on problems that go beyond the scope of the facilitator’s and project manager’s domain. However, to ensure appropriate interaction among the customer and developers, observers must not actively participate during the JAD meeting.

Here are some tips when preparing for a JAD:

  Obtain the appropriate level of coordination and commitment to using JAD. In many cases, participation in a JAD will stretch across organizational boundaries. Engineers are often from the Information Systems (IS) group, and the customer might represent users spanning several functional groups. Without concurrence of all group managers, the JAD meetings will appear biased to those not buying into the idea, causing some people to not participate or accept the outcomes. Therefore, to receive commitment to the method, the initiators of the JAD should discuss the benefits and purpose of the JAD with applicable managers of each group.
  Ensure there are clear objectives for the JAD meeting. Without clear objectives, the JAD proceedings will flounder and lead to unnecessary outcomes.


Figure 6.4  Joint Application Design meeting elements.

  Consider using an independent consultant as a facilitator. This assures neutrality and avoids siding with one particular group. Be certain, though, to avert the selection of a consultant closely allied with the department responsible for development. A close alliance could tempt the facilitator to favor the engineers, letting them dominate the meeting and hamper ideas from the customer. It doesn’t hurt to have internal people in mind to groom as facilitators; however, be sure they have proper training and are not connected to the project they’re facilitating.
  Talk to all participants before the JAD. Discuss the issues involved with the particular project, such as potential conflicts. Give all new participants an orientation to JAD if it’s their first time attending one. In some cases, the JAD might be the first time business people and engineers work together. Therefore, minimize communication problems by preparing participants to speak the same language. Avoid using computer jargon. Otherwise, communication could be difficult and customer participation will decline.
  Establish rules. Rules are absolutely necessary because the different agendas of the customer, users, and developers can often derail the JAD and raise conflicts. Rules should state that all members will conform to an agenda, all participants are equal, observers will remain silent, and the bottom line is to reach consensus on requirements. Be sure to have the participants contribute to the formation of rules.
  Don’t let developers dominate the meeting. Many JADs tend to have too many developers and not enough representation of the potential end users. This usually blocks users from expressing their ideas. In addition, there’s a tendency of IS departments using JAD to “rubber stamp” the requirements—that is, to have the customer merely review and approve them. You should limit the developers to architects and engineers because programmers might push the team toward a design too soon. The facilitator must ensure everyone has fair time to voice their ideas.

Assessing Constraints

As part of the requirements definition, you should identify which of the requirements are constraints. These are firm requirements (ones that can’t be easily changed) that limit the choice of solution alternatives. Figure 6.5 illustrates this concept. Constraints are usually requirements dealing with money, regulations, environment, existing systems, and culture. However, any requirement could be a constraint if that requirement is absolutely necessary and not subject to change. Regulations are constraints because they often carry a mandate directing a particular form of conformance. The environment, such as building size and construction, establishes constraints because the facility may be too expensive to change to accommodate certain solutions. Existing systems are not always easy to change; therefore, solutions will have to conform to particular platform constraints, memory, and so on.


Figure 6.5  The effect of constraints on solution alternatives.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.